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Resume 

Les  applications  militaires  ayant  perdu  leur  leadership 
dans  le  domaine  de  l’electronique,  elles  auront  de  plus  en 
plus  a utiliser  des  technologies  civiles.  II  faudra 
apprendre  a les  utiliser  ou  a les  adapter  a nos  specificites, 
par  exemple  faibles  volumes  en  production,  temperature 
de  fonctionnement  elevee...  L’utilisation  de  ce  que  l’on 
a pris  l’habitude  d’appeler  « composants  sur  etagere  » 
continuera  meme  si  l’assurance  de  pouvoir  les 
approvisionner  sur  le  long  terme  est  un  souci  non 
negligeable. 

Mais  une  autre  technologie,  egalement  issue  du  Civil, 
parait  prometteuse  : Les  « System  on  Chip  » ou  « SoC  ». 
En  d’autres  termes,  la  possibility  d’integrer  dans  un  seul 
circuit  ou  des  circuits  en  nombre  reduit  un  calculateur 
complet,  repondant,  par  exemple,  a une  application  de 
pilotage  / guidage  pour  missile.  Cette  approche  est 
maintenant  bien  etablie  dans  le  monde  civil  et  industriel 
tel  que  les  telecommunications,  mais  encore  relativement 
peu  implementee  dans  les  systemes  de  defense. 

II  s’agit  en  fait  d’une  technologie  ASIC  (Application 
Specific  Integrated  Circuit),  mais  integrant  jusqu’a 
plusieurs  millions  de  portes.  Pour  pouvoir  maitriser  la 
complexity  de  la  phase  de  conception  en  terme  de  cout  et 
de  delais,  les  SoC  sont  largement  bases  sur  la  notion  de 
reutilisation  de  blocs  fonctionnels : les  « Intellectual 
Properties » ou  « IP ».  En  fait,  ces  IP  ne  sont  rien 
d’autres  que  des  composants  sur  etagere  mais  virtuels, 
done  independants  d’une  quelconque  technologie.  Ils 
peuvent  soit  achetes  soit  etre  issus  de  conceptions 
precedentes.  Les  avantages  sont  nombreux,  par  exemple  : 

• II  est  possible  de  concevoir  le  SoC  sur  la  gamme  de 
temperature  voulue. 

• En  cas  d’obsolescence  d’une  technologie,  la  society 
utilisatrice  etant  proprietaire  de  la  definition  du 
circuit  peut  migrer  vers  une  technologie  plus 
recente... 


Certaines  difficultes  restent,  bien  entendu,  a surmonter 
tel  que,  et  de  maniere  non  exhaustive  : 

• L’acces  aux  fonderies,  en  cas  de  selection  d’une 
technologies  ASIC  (par  opposition  a des 
Programmable  Logic  Devices  : PLD)  du  fait  des 
faibles  volumes ; 

• La  duree  des  plannings  de  developpement ; 

• Le  cout  des  composants  virtuels. 

Tous  ces  points  sont  passes  en  revue  dans  ce  document. 


Introduction 

L’evolution  des  marches  Militaires 

L’utilisation  de  concepts  civils  pour  des  applications 
militaires  est  une  tendance  qui  peut  deja  etre  constatee  et 
qui  va  surement  s’amplifier.  Une  telle  demarche  n’est 
bien  sur  pas  sans  consequences.  L’une  d’elle  - tres 
positive  - consiste  a ecrire  des  Specifications  Techniques 
de  Besoin  souvent  mieux  dimensionnees  par  rapport  aux 
besoins  reels.  Toutefois,  certaines  contraintes 
perdureront  comme  le  besoin  de  pouvoir  fonctionner 
dans  des  environnements  difficiles.  II  n’y  a,  en  effet, 
aucune  raison  que  les  profils  et  theatres  d’operation  des 
missions  militaires  changent.  L’elevation  de  temperature 
peut  aussi  etre  due  a un  echauffement  cinetique 
(exemple  : un  missile  en  vol  fibre).  Meme  si  on  peut 
s’attendre  a des  progres  dans  la  gestion  des  calories,  cela 
ne  changera  probablement  pas  radicalement  le  probleme 
au  niveau  des  composants  electroniques. 

II  faut  noter  F impact  que  peut  avoir  la  permanente 
diminution  des  lithographies,  diminution  qui  peut 
engendrer  d’autres  phenomenes  (SEU  : Single  Event 
Upset). 


Paper  presented  at  the  RTO  SCI  Symposium  on  "Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components",  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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L’utilisation  de  concepts  civils 

Le  sujet  peut  etre  aborde  sous  deux  aspects. 

Choix  de  standards  / protocoles  et  d’elements 
d’ architecture  de  systemes  et  de  calculateurs  civils  : 

C’est  le  ller  aspect.  Pendant  la  tache  d’architecture,  un 
concepteur  peut  ainsi  selectionner  un  ou  plusieurs 
standard(s)  (exemples  : USB,  IEEE  1394,  PCI...).  II 
beneficiera  ainsi  du  support  de  la  tres  large  communaute 
utilisatrice : existence  de  la  norme,  des  outils,  des 
composants  (virtuels  et  reels,  attention  au  risque  de 
perennite  pour  ces  derniers)...  Meme  s’il  decide  de 
n’utiliser  qu’une  partie  de  ce  dont  il  peut  disposer,  il  sera 
largement  gagnant  en  terme  de  temps  (et  done  de  cout) 
de  developpement  au  moins.  Ceci  dit,  il  faut  se  prevenir 
de  l’idee  consistant  a considerer  que,  parce  que  la  norme 
existe  et  decrit  un  protocole,  tout  le  monde  - y compris 
les  neophytes  - pourront  prendre  en  charge  une 
conception.  Les  protocoles  sont  complexes  et  une  simple 
lecture  meme  approfondie  d’un  document  outre  qu’elle 
est  franchement  rebarbative  est  loin  de  remplacer 
l’experience. 

En  tout  etat  de  cause,  il  s’agit  d'une  demarche 
extremement  positive  qu’il  faut  encourager.  Le  risque 
essentiel  est  de  selectionner  un  standard  devenant 
obsolete  rapidement,  risque  limite  si  un  minimum  de  soin 
est  apporte  lors  du  choix. 

Utiliser  des  composants  issus  du  monde  civil : Il  s’agit 
du  2ieme  aspect.  La  tache  n’est  pas  si  aisee  qu'il  y parait. 

Le  probleme  de  la  gamine  de  temperature : Il  est 
necessaire  de  prevoir  la  mise  en  oeuvre  de  ces 
composants  sur  une  gamme  de  temperature  elargie. 
Accessible  pour  des  composants  simples  (transistors)  ou 
a structure  reguliere  (memoires),  l’exercice  se  complique 
notablement  pour  des  circuits  complexes  tels  que  des 
processeurs.  Ces  derniers  peuvent,  par  exemple, 
comporter  des  structures  en  partie  asynchrones  visant  a 
optimiser  les  performances  mais  qui  ne  sont  validees  par 
le  fournisseur  que  sur  la  gamme  de  temperature 
specifiee.  En  cas  d’utilisation  sur  une  gamme  elargie,  il  y 
a alors  des  risques  de  conflits  internes  lies  a des  temps  de 
propagation  tangents  (courses  de  chemin).  On  constate 
des  comportements  aleatoires  sur  une  ou  plusieurs 
plage(s)  de  temperature  plus  ou  moins  reduite(s). 

Par  ailleurs,  l’idee  consistant  a dire  que  « nos  besoins 
etant  proches  de  ceux  de  T automobile,  nous  aurons  la 
une  source  d’approvisionnement  nous  convenant » 
pourrait  bien  de  se  reveler  fausse.  En  effet,  s’il  est  vrai 
que  les  contraintes  sont  similaires,  il  est  plus  que 
probable  que  l’industrie  automobile  va  s’orienter  vers  la 
conception  de  SoC,  done  de  circuits  dedies  inaptes  a 
remplir  nos  fonctionnalites. 

Le  probleme  de  la  perennite  : Les  cycles  des  composants 
utilises  pour  des  applications  civils  sont  sans  commune 
mesure  avec  les  besoins  des  militaires.  Il  ne  s’agit  meme 


plus  de  risques  mais  d’un  element  a considerer  de  base  : 
Il  faudra  faire  evoluer  la  definition  de  tout  equipement 
militaire  tout  au  long  de  sa  duree  de  vie  pour  traiter  les 
problemes  d’obsolescence.  Le  cas  le  plus  simple  est 
lorsqu’il  suffit  de  remplacer  un  circuit  par  un  autre  de 
fonctionnalite  equivalente.  Exemple  type  : les  memoires, 
pour  peu  que  la  carte  ait  ete  congue  de  maniere  a pouvoir 
cabler  des  circuits  de  capacite  plus  importante.  L’autre 
situation  extreme,  beaucoup  plus  difficile,  est  lorsque 
qu’il  n’est  plus  possible  de  trouver  un  composant 
equivalent.  Dans  ce  cas,  il  faut  au  moins  prevoir  une 
reprise  de  la  carte  et  des  couches  basses  du  logiciel. 

Disponibilite  des  composants : Certains  composants, 
essentiellement  dedies  aux  applications  Telecom,  ou 
Automobile  par  exemple,  risquent  de  ne  plus  exister 
sous  leur  forme  classique  mais  uniquement  virtuelle. 

Information  des  fournisseurs  : Bien  entendu,  dans  tous 
les  cas  de  figure,  les  fournisseurs  restent  plutot  avares  en 
information.  Nous  serons  done  tenu  au  courant  des 
disparitions  de  composants  de  maniere  parcellaire  et 
quant  a obtenir  des  donnees  detaillees  sur  ce  qu’il  est 
necessaire  de  tester  et  comment  pour  envisager  d’utiliser 
des  circuits  sur  une  gamme  de  temperature  etendue,  la 
c’est  du  domaine  du  reve.  Non  seulement,  ils  n’y  ont 
aucun  interet  financier,  mais  en  plus  ils  ne  voudront 
surement  pas  s’engager  a nous  fournir  des  informations 
et,  en  plus,  a les  tenir  a jour  en  cas  devolutions. 

Une  solution  alternative  : Le  « System 
On  Chip  » 

Devant  un  tableau,  il  faut  bien  le  dire,  un  peu  noir, 
comment  pouvons  nous  reagir.  Il  y a probablement 
plusieurs  possibilites,  mais  dans  ce  papier,  nous  nous 
contenterons  d’en  aborder  une : Les  « Systems  On 
Chip  » ou  « SoC  ». 

Definition 

Depuis  deja  plusieurs  annees,  les  progres  des 
lithographies  sont  impressionnants  et  permettent 
d’integrer  dans  un  seul  circuit  plusieurs  millions  de 
portes.  Cela  a permis  de  developper  des  processeurs 
puissants,  mais  ceux  ci  ne  represented  fmalement 
« que  » le  marche  des  PC  et  des  stations  de  travail.  Il  y a 
bien  d’autres  applications  industrielles  ou  grand  public 
qui  peuvent  beneficier  de  ces  possibilites  et  sont  a 
l’origine  meme  du  concept  de  System  On  Chip. 

Un  SoC  est  un  circuit  dedie,  integrant  sinon  toutes,  du 
moins  les  principales  fonctions  d’un  calculateur.  Elies 
sont  relatives  a chaque  application,  mais  on  retrouve 
typiquement  : 

• 1 ou  plusieurs  coeur(s)  de  processeur 

• 1 ou  plusieurs  coeur(s)  de  DSP  (Digital  Signal 
Processing) 
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• des  peripheriques  : 

V des  interfaces  bus  systeme  (ARINC,  MIL- 
STD-1553...) 

■S  des  gestionnaires  de  liaisons  series 
■S  des  ports  paralleles 
V des  timers  / horloges  temps  reel 
■S  des  controleurs  de  commande  moteur 
(generateurs  PWM) 

• et  bien  entendu  - ce  serait  dommage  de  ne  pas  en 
profiter  - des  blocs  de  logique  dediee. 

La  figure  1 propose  un  synoptique  generique  d’un  SoC. 
On  retrouve  finalement  des  notions  proches  de  celle 


d’une  structure  de  calculateur  classique,  avec  des  blocs 
fonctionnels  connectes  a un  bus  on-chip.  Pour  ce  dernier, 
il  n’est,  malgre  tout,  pas  facilement  imaginable  de 
reprendre  des  standards  classiques  tel  que,  par  exemple 
un  bus  PCI.  En  effet,  certaines  contraintes  liees  a la 
technologie  sont  a considerer  (exemple  : eviter  d’avoir 
des  potentiels  flottants  en  interne  circuit,  done  par  de 
lignes  3 etats...).  Toutefois,  des  standards  apparaissent. 
II  convient  de  noter  les  efforts  sur  ce  sujet  d’organismes 
tel  que  VSIA  (Virtual  Chip  Interface  Alliance). 

II  est  aussi  possible  de  prevoir  des  blocs  analogiques 
ainsi  que  des  convertisseurs  analogiques  / numeriques  et 
inversement. 


Liens  de  debug  (JTAG) 


Bus  on-chip  peripherique 


E/S 


E/S 


M6moires 

externes 


Bus  on-chip  haute  performances  interne  calculateur 


Figure  1 : Synoptique  generique  d’un  SoC 


Les  marches 

Le  principal  marche  a l’origine  de  cette  tendance  est 
indubitablement  celui  des  telecommunications  qui  allie  a 
la  fois  : 

• un  fort  besoin  d’integration  pour  repondre  aux 
attentes  des  consommateurs  quant  au  poids  et  a 
l’autonomie  des  telephones  portables 

• mais  aussi  de  gros  volumes,  ce  dont  se  felicitent  les 
fondeurs. 

D’autres  applications  apparaissent,  tels  que  les 
equipements  audio  / video  et  l’automobile. 

L’ensemble  des  marches  cites  est  caracterise  par  de  gros 
volumes  en  production  associes  a des  couts  tres  faibles. 

Ce  qui  est  aussi  certain,  e’est  qu’on  ne  voit  aucun  signe 
laissant  penser  a une  inversion  de  tendance.  C’est  plutot 
le  contraire,  il  est  probable  que  l’on  verra  apparaitre  de 
nouveaux  debouches  dans  les  domaines  industriels  et 
surtout  grand  public. 

Les  grands  fournisseurs  (d’outils  entre  autres  mais  pas 
exclusivement)  l’on  bien  compris  : Il  suffit  de  faire  un 


passage  sur  les  sites  web  respectifs  ou  d’assister  a 
quelques  conferences  pour  en  etre  convaincu.  Tout 
tourne  autour  du  SoC,  a un  point  tel  qu’il  vaut  mieux  etre 
un  peu  mefiant  vis  a vis  de  ce  qui  s’en  reclame. . . 

Il  en  est  de  meme  au  niveau  de  la  presse  : Il  n’est  pas  une 
seule  publication  qui  n’ait  pas  son  lot  de  references  au 
SoC  ! 

Il  ne  s’agit  done  pas  simplement  d’un  effet  de  mode, 
mais  d’une  tendance  bien  reelle  et  durable. 

Quelques  definitions  complementaires 

Avant  d ‘aller  plus  loin,  il  est  necessaire  de  preciser 
certaines  definitions. 

Les  circuits  dedies.  Par  circuits  dedies,  on  entend  ASIC 
(Application  Specific  Integrated  Circuit)  ou  FPGA  (Field 
Programmable  Gate  Array). 

Le  synoptique  ci  dessous  (figure  2)  resume  les 
principals  etapes  d’un  developpement  type  pour  ces 
circuits.  Alors  qu’il  apparait  lineaire,  il  ne  l’est  pas  dans 
la  realite.  Par  exemple,  il  est  certain  qu’il  y a un 
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rebouclage  entre  les  phases  « Faisabilite  »,  « STB  » et 
« Architecture  ».  De  meme,  si  un  probleme  est  decouvert 
durant  une  phase  de  verification,  il  y a correction,  celle  ci 
devant  etre  effectuee  generalement  dans  l’etape 
precedente  ou  encore  avant.  Par  exemple,  un  probleme 
decouvert  en  Verification  « 2 » peut  devoir  etre  corrige 
en  retournant  a l’etape  de  « Modelisation ».  Enfin 
certaines  taches  n’ont  pas  ete  mentionnees  pour  ne  pas 
surcharger  le  synoptique.  Elies  n’en  sont  pas  moins 
importantes.  II  s’agit  de  l’insertion  de  dispositifs  de  test 
ou  encore  du  floorplan  (ou  pre -placement,  indispensable 
pour  preparer  le  routage  et  eviter  des  problemes  lors  de 
l’etape  de  Verification  « 3 »). 


Sous  forme  textuelle  et,  mieux, 
accompagnee  de  langage  C au  moins 
pour  l’algorithmie. 


Tache  fondamentale  pour  laquelle  il 
faut  accepter  de  passer  du  temps,  meme 
si  on  donne  1’impression  de  ne  pas 
avancer. 

Transcription  de  la  STB  en  description 
simulable.  Utilisation  des  langages 
HDL:  VHDL  ou  Verilog. 


Simulation, 


Transformation  du  modele  en  schema 
electrique  (SE). 


Simulation.,  analyse  de  timing. 


Dessin  des  equipotentielles  a partir  du 
SE  en  respectant  les  isolations. 


Simulation.,  analyse  de  timing. 


Realisation  des  masques  et  du  silicium. 
On  croise  les  doigt! 


Figure  2 : Flot  de  conception  d ’un  circuit  personnalise 


l’exclusivite).  Les  IP  peuvent  etre  definies  comme  des 
composants  virtuels.  Il  s’agit  done  de  blocs  fonctionnels 
qui  peuvent  etre  achetes.  Le  marche  est  particulierement 
actif  et  l’offre  tres  fournie.  On  trouve  la  plupart  des 
fonctions  listees  au  § « Definition  du  SoC  ».  Il  est  aussi 
possible  de  les  developper  en  interne  societe.  Elies 
correspondent  alors  a des  fonctions  tres  specifiques  a 
l’activite  et  que  Ton  souhaite  pouvoir  reutiliser  dans 
plusieurs  applications. 

Il  est  interessant  de  rentrer  un  peu  plus  dans  le  detail, 
sachant  que  la  maitrise  sur  le  long  terme  d’un  SoC  (ou  de 
n’importe  quel  circuit  mettant  en  oeuvre  un  IP)  est 
fonction  du  type  d’IP  utilise  (ou  instancie).  On 
distingue  : 

• Les  Soft  IP  : Les  blocs  fonctionnels  sont  decrits  en 
langage  HDL  et  sont  accompagnes  de  testbenches  et 
de  directives  de  synthese  logique.  Celle  solution 
permet  de  maitriser  entierement  le  modele  du  SoC  et 
assure  une  bonne  perennite  a long  terme.  Par  contre, 
elle  demande  un  peu  plus  de  travail  lors  de  la  phase 
de  developpement. 

• Les  Firm  IP : Les  blocs  fonctionnels  sont  fournis 
sous  forme  de  schemas  electriques.  La  encore,  des 
testbenches  sont  disponibles  ainsi  qu’un  modele 
comportemental  autorisant  les  simulations  de  haut 
niveau  (Verification  « 1 »).  Dans  ce  cas,  l’effort  de 
conception  est,  bien  entendu,  moindre  par  rapport  au 
cas  precedent.  Par  contre  on  ne  maitrise  pas  du  tous 
les  aspects  fonctionnels.  Cela  peut  etre  tres  penible 
durant  le  developpement  si  le  bloc  n’est  pas 
correctement  developpe  et  valide.  De  plus,  les 
modifications  eventuelles  ulterieures  du  SoC  seront 
plus  delicates. 

• Les  Hard  IP : Le  bloc  fonctionnel  est,  dans  ce  cas, 
synthetise,  place  et  route  par  le  fondeur.  Pour 
certains  blocs,  critiques  en  terme  de  performances  en 
vitesse,  ce  choix  est  le  meilleur.  Toutefois,  il  est 
clair  que  Ton  est  entierement  dependant  de  la 
politique  du  fournisseur  : On  n’a  aucune  maitrise  sur 
les  aspects  fonctionnels  ni,  pire  encore,  sur  la 
perennite.  Le  fondeur  peut  tres  bien  decider  de  ne 
pas  porter  une  Hard  IP  vers  une  nouvelle 
technologie  tout  en  arretant  celle  utilisee.  La 
situation  alors  delicate  a gerer,  encore  plus  s’il  s’agit 
d’un  cceur  CPU,  avec  les  impacts  logiciels  associes... 


Les  Hots  ASIC  et  FPGA  restent  tres  voisins,  etant 
entendu  qu’il  n’y  a evidemment  pas  de  fonderie  dans  le 
cas  des  FPGA  mais  la  programmation  d’une  memoire. 

Precisons  que  la  portee  de  ce  § est  bien  limitee  aux 
circuits  personnalises,  ce  qui  ne  correspond  qu’a  une 
phase  du  developpement  d’un  SoC,  dont  le  flot  complet 
sera  traite  apres 

Les  IP  ou  « Intellectual  Property  ».  La  notion  de  SoC 
est  indissociable  de  celle  d’IP  (sans  pour  autant  en  avoir 


Les  conditions  d’acces  sont  tres  variees,  rien  de  bien 
stabilise  n’ayant  deja  ete  instaure.  En  general,  il  est 
necessaire  d’acquitter  un  cout  d’acces  a la  licence,  avec 
en  plus  des  royalties  sur  les  circuits  en  production. 
Notons  que,  dans  certains  cas,  il  n’y  a pas  de  royalties  et 
qu’il  est  aussi  possible  de  disposer  d’IP  sans  droit 
d’acces  a la  licence  (meme  pour  certains  IP  consideres 
comme  complexes  tel  que  des  coeurs  CPU) ! Ceci  dit,  le 
budget  IP  est  generalement  important,  et  dependant  d 
leur  type.  Les  Soft  IP  sont,  bien  sur,  les  plus  chers. 
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Outre  le  classement  precedent,  on  distingue 

generalement  2 grandes  categories  : 

• Les  « Commodity  IP  » : Ce  sont  les  blocs  d’usage 
courant.  On  retrouve  les  fonctions  PCI,  USB, 
UART. . . L’offre  est  tres  riche. 

• Les  « Stars  IP  » : On  y classe  traditionnellement  les 
coeurs  de  processeur  et  les  fonctions  emergentes. 
Toutefois,  force  est  de  constater  que  1’on  assiste,  en 
particulier  pour  les  coeurs  de  processeur,  a des 
situations  un  peu  abusives.  La  complexity  d’un  tel 
coeur  est,  approximativement,  de  40  000  portes 
(RISC  32  bits  sans  operateurs  flottants),  ce  qui  n’est 
pas  enorme.  Les  couts  (notamment  des  soft  IP),  par 
contre,  sont  generalement  tres  eleves. 

Lors  de  la  selection  des  IP,  il  importe  de  prendre  en 

consideration : 

• Les  couts : Acces  licence,  royalties  mais  aussi 
support  / maintenance. 

• La  qualite  des  fournitures.  II  importe  de  savoir  si  un 
minimum  de  regies  de  conception  des  IP  a bien  ete 
respecte  : Conception  synchrone,  sur  fronts  montants 


uniquement,  ...  La  facilite  de  l’instanciation  des 
blocs  dans  le  modele  (et  done  couts  et  delais 
associes)  en  depend  largement.  Les  publications  a ce 
sujet  sont  nombreuses,  on  citera,  par  exemple, 
l’initiative  OpenMore  de  Mentor  / Synopsys. 

Actuellement,  la  tendance  pour  les  « Stars  IP  » est  tres 
orientee  vers  les  Hard  IP  (pour  des  raisons  de  couts  !)  et 
vers  les  Soft  IP  pour  les  autres.  Notons  toutefois  une 
evolution  encore  assez  recente  qui  apparait,  celle  des 
« Soft  IP  configurables  ».  II  s’agit  de  generer  un  bloc 
suivant  les  besoins  specifiques  (dans  une  certaine 
mesure)  de  1’utilisateur.  Ainsi,  ARC  propose,  moyennant 
le  chargement  via  Internet,  d’un  programme  permettant 
de  creer  un  coeur  de  DSP  et  l’environnement  de 
developpement  logiciel  en  fonction  d’un  certain  nombre 
de  choix.  Tensilica  offre  une  approche  similaire  peut  etre 
plus  aboutie,  aussi  pour  un  coeur  processeur  : Les  besoins 
utilisateurs  sont  decrits  via  Internet  et  la  Soft  IP  est 
generee  par  Tensilica  et  transferee,  toujours  via  le  net. 
Cette  voie  permet  des  options  de  configuration  plus 
complexes.  Nul  doute  que  cette  voie  a de  l’avenir,  ainsi 
qu’Intemet  comme  media  de  communication  et 
d’echange. 


Etudes  Systemes 
Essais  Systemes 
Definition  Algorithmes 
Etudes  architecture  produit 


MBB— 


Conception  des  Sous-ensembles 
Materiel 


Logiciel 

— Validation 
Transfert  production 


I 


Prototypes,  adaptations  aisees 

I I I 


Figure  3 : Flot  de  developpement  d ’un  SoC 


Flot  de  developpement  d’un  SoC 

La  encore,  nombre  de  publications  existent  sur  le  sujet. 
Une  chose  est  sure,  il  n’y  a pas  de  flot  standard, 
applicable  quel  que  soit  le  type  d’activite  de  la  societe. 
Dans  ce  §,  on  va  done  s’attacher  a preciser  les  grandes 
etapes  a prevoir  avec  les  differentes  options  possibles 
pour  chacune  d’elles  ainsi  que  quelques  ecueils  a eviter. 

On  partira  pour  ce  faire  du  synoptique  de  la  figure  3. 

Le  flot  propose  est  base  sur  la  realisation  d’une  maquette 
a base  de  FPGA  en  plus  du  developpement  des 


prototypes  en  forme  mettant  en  oeuvre  le  SoC.  C’est  un 
choix  dont  Tinteret  est  decrit  dans  un  des  § suivants. 

Implication  des  equipes  Systeme 

Le  l'er  point  a preciser  est  qu’il  n’est  pas  imaginable  de 
dissocier  les  aspects  Systeme  / Algorithmique  du 
processus  de  conception  d’un  SoC.  Si  cette  demarche  est 
sans  doute  tres  presente  dans  la  culture  d’entreprises  du 
domaine  des  Telecommunications,  elle  Test  beaucoup 
moins  dans  des  societes,  par  exemple  de  1’aeronautique. 
Deux  raisons  a cela  : 
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• L’historique  des  Societes 

• Les  differences  existant  au  niveau  de  la  notion  de 
systeme.  Dans  le  domaine  de  l’aeronautique,  le 
systeme  met  en  oeuvre  un  ensemble  d’equipements 
complexes,  pas  necessairement  bases  sur  les  memes 
technologies  (mecaniques,  optiques. . .). 

Les  responsables  du  Systeme  et  de  la  definition  des 
algorithmes  doivent  etre  tres  impliques  dans  les  etudes 
d’architecture.  II  est  necessaire  d’optimiser  les 
algorithmes  et  de  les  orienter  en  vue  d’en  faciliter 
l’implementation.  Cette  demarche  etait  classique,  voire 
naturelle  au  tout  debut  de  l’electronique  essentiellement 
a cause  des  limitations  de  cette  technologie  naissante. 
Elle  s’est  - a tord  - largement  affaiblie  avec  la 
generalisation  des  structures  programmables.  II  parait 
sain  de  la  remettre  au  gout  du  jour  non  pas  du  fait  de 
limitations  technologiques  mais  plutot  de  couts  en 
production. 

Par  ailleurs,  en  cas  d’erreur  decouverte  une  fois  le  SoC 
realise,  toute  modification  risque  d’etre  longue  et 
couteuse  si  une  solution  logiciel  n’est  pas  applicable. 
Fort  heureusement,  on  commence  a voir  apparaitre  des 
outils  permettant  la  fourniture  de  Specifications 
Techniques  de  Besoins  (STB)  simulables  done  d’une  part 
validees  par  rapport  aux  besoins  et  d’autre  part  pouvant 
servir  de  modele  de  reference  pour  la  conception  du  SoC. 
II  convient  enfin  de  noter  qu’il  est  beaucoup  plus  difficile 
de  valider  par  simulation  des  evenements  asynchrones 
que  synchrones.  Meme  si  ce  n’est  pas  toujours  possible, 
on  cherchera  a les  eviter. 

Le  plan  de  developpement 

Le  2,eme  point  important  est  de  definir  en  debut  d’affaire 
le  plan  de  developpement  et  de  preciser  entre  autres  : 

• S’il  est  necessaire  de  passer  par  une  phase  maquette. 

• Les  differentes  etapes  de  validation  et  les  entrees 
necessaires  a celles  ci. 

• Le  planning,  bien  entendu,  avec  le  calage  du  debut 
du  developpement  du  prototype  en  forme. 

Passage  par  une  phase  maquette 

II  est  fortement  souhaitable  pour : 

• Pouvoir  mettre  au  plus  vite  a disposition  des  equipes 
Systeme  des  versions  intermediates  de  calculateur. 

• Envisager  l’integration  materiel  / logiciel  avant  de 
pouvoir  disposer  du  prototype  en  forme. 

Besoin  des  equipes  Systeme.  Disposer  au  plus  vite  de 
calculateurs  permet  aux  equipes  Systeme  de  commencer 
progressivement  les  integrations.  II  est  clair  qu’au  debut 
de  celles-ci,  il  n’est  pas  necessaire  de  pouvoir  activer 
toutes  les  fonctionnalites  prevues  pour  le  calculateur.  La 
gestion  des  E/S  sera  done  initialement  proposee  et 
completee  progressivement  en  fonction  des  souhaits  emis 
au  niveau  Systeme. 


Cette  demarche  est  aussi  une  aide  pour  les  concepteurs 
du  calculateur.  Meme  si  les  simulations  permettent 
d’aller  tres  loin  dans  la  validation,  on  ne  peut  simuler  que 
ce  dont  on  a les  modeles.  Ce  n’est  pas  necessairement  le 
cas  de  tous  les  elements  connectes  au  calculateur.  Dans 
ce  cas,  on  ecrit  un  modele,  mais  qui,  souvent  simplifie, 
ne  represente  pas  toujours  le  comportement  reel.  Les 
essais  avec  les  equipements  reels  sont  de  bon  tests. 

Integration  Logiciel.  L’autre  interet  majeur  de  disposer 
d’une  maquette  est  de  pouvoir  commencer  l’integration 
Logiciel  avant  d’ avoir  le  prototype  en  forme.  A ce  sujet, 
on  voit  apparaitre  une  multitude  d’emulateurs  ou 
d’accelerateurs  Materiel  dont  on  retrouvera  Pinteret  au 
niveau  des  simulations  apres  synthese.  Ce  genre  de 
moyen  peut  etre  utilise  pour  faciliter  F integration  logiciel 
lorsque  l’on  cherche  a effectuer  celle  ci  en  utilisant  le 
modele  HDL  du  SoC.  Complete  avec  des 
environnements  de  co-simulation  (tel  que  Seamless  de 
Mentor  ou  Eagle-i  de  Synopsys...),  il  est  possible,  pour 
les  equipes  logiciel  et  de  developpement  du  SoC  de 
travailler  chacune  dans  leur  environnement.  De  plus,  en 
simulation,  tous  les  nosuds  internes  du  circuit  sont 
accessibles,  ce  qui  facilite  grandement  le  debuggage. 
Enfin,  au  niveau  du  SoC,  le  logiciel  applicatif  constitue 
un  testbench  reve.  Malheureusement,  il  convient  de 
rester  realiste : La  puissance  des  machines,  meme 
associees  a un  accelerateur,  reste  en  depa  des  besoins 
necessaires  a la  simulation  d’un  logiciel  applicatif 
complet.  On  limitera  done  cette  approche  au  niveau  des 
handlers  de  base  du  logiciel. 

La  mise  en  oeuvre  d’accelerateurs  n’est  pas  evidente.  Ils 
represented  un  investissement  consequent  et  reposent 
soit  sur  des  structures  proprietaries  soit,  e’est  de  plus  en 
plus  souvent  le  cas,  sur  des  FPGA.  Dans  ce  cas,  bien 
souvent,  il  faut  aussi  disposer  de  la  chaine  de 
developpement  FPGA.  Il  sera  necessaire  de  considered 
pour  le  developpement,  la  tache  de  partitionnement  vers 
plusieurs  FPGA  avec  aussi  les  etapes  de 
placement  / routage  de  chacun  d’eux.  C’est  assez  lourd. . . 
et  redondant  avec  la  maquette.  Enfin  dernier 
inconvenient  relatif  a ce  genre  d’investissement : La 
perennite  est  limitee  ! En  effet,  ces  moyens  reposent  sur 
des  technologies  tres  evolutives  (FPGA),  done 
rapidement  obsoletes. 

Les  etapes  de  validation 

Le  synoptique  de  le  figure  3 le  montre,  les  etapes  de 
validation  sont  nombreuses  et  menees  a bien  par  des 
equipes  differentes.  Par  ailleurs,  on  s’en  doute  bien,  elles 
sont  fondamentales,  d’ou  Pinteret  de  les  preparer 
soigneusement.  Il  est  done  largement  souhaitable 
d’etablir  un  plan  de  validation  le  plus  tot  possible  apres 
le  plan  de  developpement  et  decrivant  chaque  etape  de 
validation  avec  les  entrees  / sorties,  qui  fournit  quoi  et 
qui  fait  quoi.  Cela  presente  les  avantages  : 

• de  s’assurer  que  rien  n’aura  ete  oublie  (validation 
de  certains  modes  fonctionnels) 
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• de  ne  pas  non  plus  valider  2 fois  la  meme  chose,  ce 
qui  peut  couter  cher  en  temps 

• de  fiabiliser  le  planning  de  developpement,  en 
precisant  les  responsabilites. 

Ce  plan  de  validation  doit  etre  tenu  a jour  et  enrichit  en 
permanence. 

On  se  limitera,  dans  ce  §,  aux  validations  fonctionnelles. 
Les  techniques  de  validation  sont  essentiellement  basees 
sur  des  simulations,  associees  a des  essais  effectues  avec 
les  maquettes  et  prototypes. 

Les  simulations.  Plus  les  simulations  sont  faites  a haut 
niveau,  plus  elles  sont  rapides.  On  a done  tout  interet  a 
envisager  de  commencer  au  niveau  Systeme,  en  creant 
des  Specifications  Techniques  de  Besoins  simulables. 
Les  validations  de  haut  niveau  peuvent  ainsi  etre  faites 
directement  par  Tequipe  systeme  ce  qui  est  plus  efficace. 

Au  niveau  des  modeles  developpes  pour  les  besoins  de  la 
phase  Maquettage,  la  priorite  est  d’en  disposer 
rapidement.  Les  simulations  sont  done  reduites  (ce  qui  ne 
veut  pas  dire  supprimees),  mais  completees  par  des 
essais  sur  table. 

Le  SoC,  quant  a lui,  doit  etre  valide  de  maniere  intensive 
et  a toutes  les  etapes  de  conception.  II  convient  de  noter 
que  les  simulations  fonctionnelles  sont  longues. 

Au  niveau  du  modele  HDL,  le  temps  passe  est 
essentiellement  du  a la  definition  des  themes  de  test  et  a 
la  creation  des  testbenches  correspondants.  De  plus,  il  est 
souvent  difficile  de  savoir  si  la  validation  est  exhaustive 
ou  non.  C’est  particulierement  vrai  pour  des  applications 
de  traitement  d’images.  Par  contre,  les  temps  machine 
restent  acceptables. 

Par  ailleurs,  il  faudra  bien  comparer  les  resultats  de 
simulation  par  rapport  a une  reference  et  ce  de  maniere 
automatique.  On  voit  bien,  la  encore,  T interet  de  disposer 
d’une  Specification  Technique  de  Besoins  simulable. 
Pour  revenir  a la  definition  des  themes  de  test,  il  est 
important  d’y  associer,  bien  sur  les  concepteurs  du  SoC, 
mais  aussi  les  utilisateurs  : 

• au  niveau  systeme,  y compris  les  responsables  de  la 
definition  des  algorithmes,  et  ce  pour  eviter  toute 
incomprehension 

• au  niveau  carte,  de  maniere  a fiabiliser  la  definition 
des  interfaces  avec  le  reste  des  circuits  des  cartes. 

• au  niveau  logiciel,  c’est  aussi  a ce  niveau  que 
Tutilisation  des  handlers  logiciel  de  base  constitue 
un  excellent  testbench,  ainsi  que  cela  a deja  ete 
precise. 

Apres  synthese  et  placement  / routage,  les  temps  des 
simulations  fonctionnelles  sont  fondamentalement 
prohibitifs.  Pour  assurer  la  coherence  des  tests,  elles  ont 
pour  base  les  testbenches  definis  au  niveau  de  la 
validation  du  modele  HDL.  Mais,  du  fait  de  la  forte 
complexite  de  ces  circuits,  les  temps  machine  sont 
importants,  pouvant  durer  plusieurs  semaines  (sur 


plusieurs  stations  de  travail).  On  limite  done  ce  type  de 
simulation  au  strict  minimum  et  on  s’attache  plutot  a 
utiliser  un  outil  d’analyse  statique  de  timing.  Celui  ci  est, 
de  toute  fapon  indispensable  a une  validation  correcte  au 
niveau  structurel  (apres  synthese).  Eventuellement,  des 
outils  de  preuve  formelle  peuvent  constituer  aussi  une 
aide  mais  ils  ne  marchent  generalement  pas  tres  bien 
pour  des  structures  algorithmiques  complexes,  du  moins 
actuellement. 

Essais  sur  table.  Ce  type  d’essai  est  tres  classique.  On 
notera  tout  de  meme  : 

• T interet  qu’il  y a de  bien  les  formaliser  de  maniere 
a eventuellement  les  transformer  en  testbench 

• en  cas  de  probleme,  Pimportance  qu’il  y a de 
fiabiliser  la  coherence  des  prises  en  compte  des 
corrections  au  niveau  des  maquettes  (FPGA)  mais 
aussi  au  niveau  du  SoC 

Enfin,  meme  sur  maquette,  en  cas  de  probleme,  il  est 
souvent  plus  facile  d’en  trouver  Torigine  en  simulation 
ou  Ton  a acces  a Pensemble  de  nceud  du  circuit,  plutot 
que  sur  la  realisation  materielle. 

La  gestion  des  plannings 

On  Ta  vu,  une  bonne  gestion  des  etapes  critiques  permet 
logiquement  de  fiabiliser  le  planning  de  developpement. 
L’autre  aspect  a maitriser  est  la  relation  avec  les 
intervenants  exterieurs. 

Sous-traitance  de  conception  : Elle  n’est,  bien  sur,  pas 
obligatoire.  Dans  le  cas  ou  on  y a recourt,  en  particulier 
pour  la  conception  de  blocs  fonctionnels  en  HDL,  il  est 
souhaitable  d’imposer  des  regies  de  conception  qui 
permettent  de  s’ assurer  de  la  qualite  de  conception  et 
d’un  interfaqage  aise  avec  le  reste  du  circuit 

La  encore,  les  recommandations  definies  dans  le  cadre  de 
T initiative  OpenMore  sont  une  excellente  base. 

Il  est  aussi  largement  preferable  que  le  sous-traitant 
utilise  les  memes  outils  de  conception  que  ceux  mis  en 
oeuvre  dans  la  societe. 

Placement  / routage,  relations  avec  le  fondeur : Il 

s’agit  d’un  cas  un  peu  particulier  de  sous-traitance.  C’est 
souvent  le  fondeur  qui  se  charge  du  placement  / routage 
etape  souvent  assez  delicate  et  qui,  en  cas  de  probleme 
peut  durer  fort  longtemps.  Deux  regies  essentielles  sont  a 
respecter : 

• Meme  si  Ton  cherche  a etre  independant  des 
technologies,  il  est  souhaitable  de  selectionner  le 
fondeur  au  plus  tot,  et  de  mettre  en  place  des 
echanges  sur  l’avancement  du  projet  et  les  regies  de 
conception  qu’il  peut  vouloir  imposer. 

• Avant  d’envoyer  un  circuit  pour  le 
placement  / routage,  on  aura  tout  interet  a passer 
par  une  etape  de  pre-placement,  et  de  prendre  en 
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compte  le  routage  de(s)  horloge(s).  Cela  evite 
nombre  d’allers  / retours,  souvent  penibles  et  longs. 

Plannings  trop  optimises  : Bien  sur,  le  developpement 
doit  etre  le  plus  court  possible.  II  ne  faut  tout  de  meme 
pas  tomber  dans  le  piege  consistant  a « oublier  » des 
taches.  En  particulier,  il  ne  faut  pas  considerer  que,  parce 
qu’on  utilise  des  IP,  il  n’y  a aucun  effort  de  conception  a 
prevoir.  Il  y a generalement  une  logique  d’interfaqage  a 
concevoir.  Un  bon  exemple  est  celui  du  couplage  d’un 
coeur  CPU  sur  un  bus  on-chip.  Il  serait  bien  surprenant 
que  les  2 blocs  aient  ete  conpus  en  meme  temps,  sans 
evolution  aucune  de  Tun  par  rapport  a P autre. 

Recouvrement  des  activites  de  conception  FPGA 
(maquette)  / SoC  : A condition  de  bien  le  prevoir  au 
niveau  de  l’architecture  des  circuits,  il  est  imaginable  de 
reprendre  des  blocs  HDL  developpe  pour  la  maquette 
pour  le  SoC  proprement  dit  et  inversement.  Par  contre,  il 
faudra  faire  attention  a la  coherence  des  fichiers,  en 
particulier,  suite  a la  prise  en  compte  des  evolutions. 

Integration  Materiel  / Logiciel  et  Systeme 

Ce  theme  a deja  ete  aborde  pour  justifier  l’interet  de  la 
phase  Maquette.  Toutefois,  a un  moment  donne,  il  faudra 
bien  integrer  le  prototype  en  forme  avec  le  SoC...  et  bien 
sur,  il  y aura  des  problemes  ! 

Au  niveau  logiciel,  les  techniques  de  debuggage  n’ont 
aucune  raison  d’etre  differentes  de  celles  utilises  avec 
des  structures  programmables  classiques. 

Au  niveau  systeme,  il  est  certain  qu’il  faut  prevoir  des 
dispositifs  integres  dans  le  SoC  et  permettant  - au 
minimum  - de  connaitre  les  donnees  echangees  entre 
blocs. 

Enfin,  rappelons  l’interet  qu’il  y a a disposer  d’un 
modele  et  permettant  un  debuggage  souvent  facilite, 
moyennant  la  definition  d’un  test  precis. 


Technologie  et  perennite 

Avantages  / inconvenients  de  l’approches  SoC 

Les  avantages  de  l’approche  decrite  se  retrouve  a divers 
niveaux  : 

Les  aspects  thermiques,  la  consommation  : L’integration 
silicium  permet  souvent  de  diminuer  la  puissance 
dissipee.  Si  la  consommation  n’est  generalement  pas  un 
probleme  pour  des  applications  aeronautiques,  les 
aspects  thermiques  eux  le  sont.  Le  choix  d’une 
technologie  ASIC  (avec  fonderie)  par  rapport  a une 
filiere  FPGA  est,  a ce  sujet  preferable. 

Les  couts  en  production  : Les  structures  de  ce  type  sont 
beaucoup  plus  simples,  mettant  en  oeuvre  moins  de  cartes 
et  moins  de  composants.  Autant  de  facteurs  reducteurs  de 


cout  en  production.  La  consommation  diminuant,  on 
gagne  aussi  sur  la  complexity  des  blocs  alimentation. 

Les  dispositifs  de  drainage  des  calories  se  simplifient. 

La  fiabilite : La  maitrise  de  la  consommation  et  la 
reduction  du  nombre  de  composants  permettent 
d’ameliorer  la  fiabilite  des  calculateurs. 

Les  inconvenients  : Bien  sur,  il  y en  a toujours  : 

Acces  fonderie  : Dans  le  cas  du  developpement  d’un  SoC 
base  sur  une  technologie  ASIC  (par  opposition  a FPGA). 
La  lithographie  a utiliser  sera  du  0.25  ou  0.18  pm.  Les 
couts  de  realisation  des  masques  sont  importants.  De 
plus,  les  fondeurs,  surtout  actuellement,  recherchent  de 
gros  volumes  ce  qui  n’est  absolument  pas  notre  cas  au 
niveau  des  applications  aeronautiques.  Il  convient  de 
remarquer,  pour  ces  2 aspects  que  ce  debat  sur  l’acces 
aux  fonderies  date  du  debut  de  la  technologie  ASIC. 
Jusqu’a  maintenant,  nous  avons  toujours  trouve  des 
fondeurs  acceptant  de  travailler  avec  nous.  Par  ailleurs, 
des  techniques  d’acces  multi-projects  wafer  et  multi  level 
mask  se  developpent,  limitant  l’envole  du  prix  des 
masques. 

Conditions  d 'achat : C’est  bien  connu  : Les  societes  ont 
horreur  d’acheter  de  grosses  quantites  couvrant  les 
besoins  de  plusieurs  annees.  C’est  malgre  tout  ce  qu’il 
faut  se  preparer  a faire  ! En  effet,  pour  un  SoC  developpe 
en  technologie  ASIC,  on  demandera  au  fondeur  de  lancer 
un  batch  de  wafers,  ce  qui  representera  sans  doute  si  ce 
n’est  toute,  au  moins  une  bonne  partie  de  la  serie  ! Ceci 
dit,  ce  probleme  est  aussi  de  plus  en  plus  souvent 
rencontre  dans  le  cadre  de  l’utilisation  de  composants 
civils,  et  done  de  FPGA. 

Risques  et  couts  de  developpement : Des  que  l’on  parle 
ASIC,  on  voit  souvent  les  cheveux  de  dresser  sur  la  tete 
de  nos  interlocuteurs  ! A tord  ! Finalement,  le  cout  de 
developpement  d’une  fonction  en  ASIC  est  similaire  a 
celui  d’une  structure  programmable  aux  couts  de 
fonderie  prets.  Meme  si  ces  derniers  sont  eleves,  ils  ne 
sont  malgre  tout  pas  redhibitoires  par  rapport  aux  couts 
de  developpement  d’un  calculateur.  Par  ailleurs,  les 
outils  et  les  methodologies  utilises  permettent  de 
largement  fiabiliser  le  developpement  et  de  done  de 
reduire  les  risques. 

Souplesse : Bien  sur,  une  fois  la  phase  de  fonderie 
terminee,  il  est  sinon  difficile  en  tout  cas  long  et  couteux 
de  modifier  une  fonction  pour  prendre  en  compte  une 
evolution.  Il  est  important  d’insister  la  sur  l’etape 
d’architecture  de  maniere  a rendre  la  structure 
parametrable  (exemple  : pouvoir  modifier  les  parametres 
d’un  filtre  par  programmation).  De  plus,  on  1’a  vu,  le 
SoC  integre  beaucoup  de  blocs  standards,  le  tout  controle 
par  logiciel  du  fait  de  l’integration  d’un  coeur  CPU  (ou 
plusieurs).  L’idee  de  circuits  ASIC  rigides  n’est  done 
plus  vraiment  de  mise  et,  en  tout  cas  ne  l’a  jamais  ete 
pour  les  technologies  FPGA.  Enfin,  le  cote  positif  est  que 
« Reflechir  avant  d’agir  » permet  souvent  d’eviter  des 
erreurs  et  de  gagner  en  temps  de  developpement... 
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Meme  si  la  decision  est  prise  de  s’orienter  vers  du 
FPGA,  il  est  souliaitable  de  conserver  la  possibility  de 
migrer  vers  de  FASIC  et  done  d’appliquer  les  regies 
idoines.  On  commence  a voir  apparaitre  des  FPGA 
integrant  des  cceurs  de  processeur : Attention  a la 
compatibility  avec  une  possible  filiere  ASIC. 

Le  FPGA  est,  bien  entendu,  plus  souple  en 
developpement  en  cas  devolution  mais  est  notablement 
plus  cher  en  production.  II  faut  done  faire  un  bilan 
economique  en  fonction  des  quantites  a produire. 

Le  FPGA  presente  aussi  le  risque  d’obsolescence.  Alors 
que  les  memoires  SRAM  etaient  le  vehicule 
technologique  utilise  par  les  fondeurs  pour  mettre  au 
point  les  nouvelles  lithographies,  elles  ont  ete  remplacees 
par  les  FPGA  qui  ont  aussi  une  structure  reguliere  et 
pour  lesquels  on  assiste  a l’envole  des  complexites.  Ces 
composants  sont  done  a la  pointe  des  technologies,  mais 
cette  course  risque  de  laisser  rapidement  de  cote  les 
versions  a peine  plus  anciennes.  II  y aura,  bien  sur,  des 
FPGA  permettant  de  remplir  la  fonction,  mais  la 
compatibility  avec  la  carte  n’est  pas  assuree. 

Au  moment  du  choix,  il  convient  d’etre  prudent  par 
rapport  a la  realite  des  complexites  annoncees  par  les 
fournisseurs  de  FPGA.  1 million  de  portes  FPGA  est  loin 
d’etre  equivalent  a 1 million  de  partes  ASIC  ! En  plus  le 
rapport  est  variable  en  fonction  des  fournisseurs  et  meme 
des  families.  Idem  pour  les  vitesses  qui  correspondent 
souvent  a des  « best  case  »,  c’est  a dire  la  frequence 
maximum  avec  des  fan  out  de  1 . . . ce  qui  est  rarement  le 
cas  dans  la  realite  ! 

La  perennite 

Ce  theme  est  la  trame  de  ce  document  en  entier,  avec, 
toutefois,  quelques  aspects  complementaires. 

Propriety  du  circuit : La  society  est  proprietaire  de  son 
design  et  du  modele  HDL.  Moyennant  le  respect  de 
quelques  regies,  le  portage  d’une  technologie  vers  une 
autre  n’est  pas  un  probleme  majeur. 

Une  limitation  existe  en  cas  d’utilisation  de  Firm  ou 
Hard  IP,  pour  lesquelles  il  faudra  se  limiter  a de  grands 
standards  du  marche. 

A noter,  que,  a ce  niveau,  il  ne  s’agit  pas  de  dire  que  la 
technologie  (lithographic)  ne  deviendra  pas  obsolete.  Par 
contre  le  fait  de  pouvoir  migrer  vers  une  autre,  meme  si 
les  couts  ne  sont  pas  nuls,  permet  d’eviter  la  reprise  de 
cartes  et  pire  encore  du  logiciel. 

Conditions  d’achat : Cedes  la  meme  evoquees 

precedemment  et  presentees  comme  un  inconvenient  ! Le 
fait  de  faire  du  stock  en  quantity  suffisante  pour  la  serie 
met  a 1’abrie  de  tout  surcout  du  fait  de  problemes 
d’obsolescence... 


Gamrae  de  temperature  de  fonctionnement : A partir 
du  moment  oil  la  society  controle  l’ensemble  du 
developpement,  il  est  parfaitement  possible  de  valider  le 
SoC  (les  timings)  sur  une  gamme  de  temperature 
correspondant  a nos  besoins.  En  production,  si  le  fondeur 
refuse  d’effectuer  les  tests  en  temperature,  il  est  encore 
possible  de  realiser  ou  de  faire  realiser  des  tests 
specifiques  puisque  l’on  est  aussi  proprietaire  des 
vecteurs  de  test. 


Conclusion 

L’approche  SoC  necessite  d’adapter  certaines  methodes 
de  developpement  au  niveau  validation  par  exemple  et 
d’effectuer  un  controle  rigoureux  du  developpement.  Par 
contre,  elle  est  particulierement  attractive  sur  les  plans 
des  performances  au  sens  large  mais  aussi  de  la 
perennite. 
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